CORS 配置不当
CORS 是浏览器的 强制策略:并非「防攻击的锁」,但 错误配置 会扩大跨站读能力、与 携带凭证 组合时风险更高。
危险配置示意(服务端)
http
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true规范上 Access-Control-Allow-Origin: * 与 Allow-Credentials: true 不能同时用于实际带 Cookie 的响应;若实现不严谨,可能退化为 反射请求 Origin 的误配,把信任域扩得过大。
另一常见误配:
http
Access-Control-Allow-Origin: null部分场景下 Origin: null 可来自 file:// 或沙箱页面,被误信。
攻击面说明
- CORS 不防 CSRF(简单请求仍可能发出去),但 错误 CORS 可让恶意站 用浏览器读 到用户身份下的 JSON 响应(若凭据与反射 Origin 被错误放开)。
正确思路:白名单 Origin
http
Access-Control-Allow-Origin: https://app.example.com
Vary: Origin对预检 OPTIONS 与真实请求 一致;只信任业务需要的 https 源。
前端注意点
- 需要 Cookie 时:
fetch(url, { credentials: 'include' });同时服务端必须 精确 Allow-Origin 且Allow-Credentials: true。 - 勿在公网 API 上 用通配
*搭配 用户私有数据。
小结
CORS 应 白名单化、对 Vary: Origin 有清晰缓存策略;鉴权与数据权限 仍必须在服务端与 Token 里实现,不能依赖「跨域开没开」。
